Computing devices include nonvolatile memory containing information used when rebooting, and volatile memory that is changed dynamically during operations. Thin client and embedded operating systems often restart from nonvolatile memory in the form of flash memory. Particularly for flash memory but also for other forms of nonvolatile memory such as hard disk partitions, memory access is relatively slower than directly addressable volatile RAM. For some purposes, executable code may be provided in addressable read-only memory, but in large part, executable code and other operating particulars are loaded from the nonvolatile memory to RAM during startup operations and directly addressed in the RAM by a central processing unit at runtime.
Limited use is made of the nonvolatile memory, which is less convenient and typically slow, and is used to store values that are less frequently changed. It also may be prudent to limit the extent to which operating system files can be changed freely. Values stored in nonvolatile memory devices, such as a disk partition or a flash memory, have the important aspect that their values are not lost when the system is powered down. Nonvolatile memory is used to store a starting version of the system, including executable code and parameter values that are to govern operation when the system is restarted. It is advantageous to have a capability to alter the contents of the nonvolatile memory, for making relatively long-lived or permanent changes, such as configuration changes, installation of new or revised versions of executable code, and otherwise setting memory contents that will be infrequently changed.
One technique is to provide in volatile RAM a block of data that stores a version or image of the nonvolatile memory contents in which changes can be made. The block in RAM can be changed during runtime operations, with appropriate programming regulating the extent to which changes are permitted. At some point, the block in RAM is written over the corresponding block in the nonvolatile version so that the changes appear at the next system restart, i.e., to make the changes permanent. In the case of a flash memory, which takes some time to write, a regular orderly shutdown procedures can the step of writing the revised version from the block in RAM to the flash memory. Except in the case of a catastrophic shutdown such as a power failure, wherein the orderly shutdown procedure cannot be completed, changes made to the operating system can become permanent in the flash memory in this way.
It is a programming issue to decide how freely operational changes might be permitted. Certain file attributes can be associated with memory files to define them as hidden or write protected, etc. Files with particular attributes can be made accessible only to processes with a given set of authorizations, and only certain processes might have the necessary rights to alter file attributes. Setting up and regulating changes are generally programming choices.
The Microsoft Windows XP-embedded system has a software aspect known as the Enhanced Write Filter (“EWF”) by which changes to be made to a block of nonvolatile memory of an embedded operating system, for example a flash memory, can be controlled. The EWF feature controls whether or not the changes that are accumulated in an image of the block in RAM will be written to the flash memory during orderly shutdown procedures, and thus made permanent for use at the next reboot. The EWF feature either permits the entire block to be written or prevents the entire block from being written. EWF lacks a selective commit applicable to make permanent only certain selected files, or subdirectories or other categories of information in the block, which may have changed is size or position. Otherwise, changes in RAM are either committed to all become permanent (at least insofar as being written to nonvolatile memory so as to survive the next restart), or none are committed. EWF since Service Pack 2 (SP2) can selectively commit files, but only if their size and position has not changed.
Memory management is an important issue in so-called thin client computer systems, which preferably comprise terminal devices having a limited nonvolatile flash memory as opposed to a hard disk. Much of the programming to be operated via the thin client terminal device is run at a server that serves a network of thin clients. The programming at the terminal device in part is for accessing the server, and in part is to run code that is obtained from the server.
A number of models of thin client computer systems, including systems using the Windows XP-embedded systems “XPe”), are distributed by Neoware Systems, Inc., King of Prussia, Pa. Although such systems use nonvolatile read/write data storage such as flash memory to coordinate execution of software at a server, it still occurs that changes to programming and configuration of the client terminal may be needed from time to time. Hardware reconfigurations, new versions of software and changes in user rights might provide reason to reprogram all or part of the flash memory. In some situations, such changes are made under remote management from the server and/or a network administrator. It is helpful if remote changes can be implemented without immediately committing either to discard or to keep all of the changes at the next system restart (generally termed a “reboot”) and preferably without the need to reboot to effect the changes in the first place.
The Neoware Windows XPe configuration can support many features including Web applications such as full browser operation with the ability to support plug-ins, COM objects, JVM Adobe Acrobat, Macromedia Flash, and ActiveX. Neoware XPe thin clients are resistant to viruses and worms because applications run on the server, not the desktop. Management options include Neoware's ezRemote Manager, IBM Tivoli, Altiris Deployment Server, and Microsoft Systems Management Server 2003 (SMS). In these systems, the client terminal is typically provided with a moderately substantial flash memory, for example, 256 or 512 megabytes, which is nonvolatile and stores executable code downloaded from the server. For example, the code contains overlays that are written to RAM when needed for execution of associated operations. The flash memory also has memory locations available for storage of system setup parameters.
According to choices made in programming, a computer system might be programmed to permit alteration of executable program segments and constants stored in a nonvolatile read/write memory on disk or flash media or otherwise. Alternatively, the computer system might be programmed to limit the extent to which programs and constants are alterable. Using hardware, a computer system might employ a read-only memory (ROM) device for executable instructions and/or constants that need to survive a restart, together with a random access memory for values that are to be changeable and need not survive a restart.
If all the parameters needed to initiate a system are stored in a nonvolatile way, and the contents of the volatile RAM are lost when the system is powered down, the system will restart very dependably, always in the same way. However, such a system is not reconfigurable. It is advantageous to provide data values that can be changed, but can survive a restart.
A typical computer for business and personal use employs a combination of more or less volatile storage. On a hardware level, there may be circuit board jumpers physically placed to make selections among supported options. An initial bootstrap loading routine is provided in read-only storage and defines initial instructions upon startup. The basic input output system (BIOS) may be stored in a set of nonvolatile registers such as a flash memory in a way that permits changes to be made but only during a startup procedure that precedes loading of the main operating system. The executable system software is loaded from disk and typically is hierarchical, with an operating system such as Window XP containing programming and constant values is a system registry, used to oversee and control the execution of applications programs. On another level, sometimes there are plural defined sets of user preferences. Changes made to the system may need to be made above the user preference level so as to affect all users, or below that level to affect only the requesting user.
In any event, it is advantageous from time to time to make changes, for example when reconfiguring a system, when changing hardware configuration and the like, and it is advantageous to protect the system and its setup. The Windows XP system has a System Restore feature wherein sufficient information is stored on a system disk to wholly define a previous setup. If a user makes a change and the results are less than expected, the user has the option to revert to a previous setup. The user can continue to experiment with alternative changes, reverting to a previous setup as necessary, until the desired results are obtained.
The Windows embedded XP system (XPe) has a feature identified as the enhanced write filter or “EWF.” This feature resembles System Restore in a way applicable to embedded systems and is used to undo the effect of memory-write operations. The actual write operations are made only logically during runtime by a processor to a memory buffer area, and not irrevocably to the flash or other memory of the Windows embedded XPe system. A flash memory is writable but the write process is slow, such that the flash memory has attributes much like a programmable read only memory. This enables the system to operate as if the flash memory is a read/write RAM. At some point, such as at orderly shutdown, the memory buffer area is copied over the flash memory and becomes the new nonvolatile system memory that is used during the next system restart. The EWF feature allows the operating system to choose whether the changes made to the buffer will be copied over the flash memory or discarded, in which case the next system restart will be the same as the last one.
To invoke the Windows EWF feature, an image of the flash memory (or other protected memory block) is stored as an overlay in a RAM buffer. Memory read and write operations that are to be directed to the protected block are redirected to the overlay. During programmed operations, the contents of the affected memory locations may change in the buffer but not in the protected memory block in the flash.
Assuming that the protected block stored system configuration information or executable code, the contents are likely to be changed only in certain situations, such as a change of configuration, the installation of new or revised software, etc. Nevertheless, it is advantageous to have a way to make changes to these portions. The EWF feature is intended to facilitate such changes but not to make the changes lightly. At some point in operation, such as during a shutdown procedures, the contents of the memory buffer are copied over the protected block, or by software selection are specifically not copied and thus are discarded. In this way, the EWF feature permits the XPe operating system either to accept or decline changes made between the original condition of the protected block as copied into the memory buffer, and the final condition after running for a time and possibly making configuration changes.
The option in XPe-EWF to make memory changes permanent is useful to limit the extent to which memory content changes can be made accidentally, e.g., as a result of programming errors or anomalous conditions. At the same time, the system has the ability when necessary to make intended setup changes. This arrangement is intended to provide many of the dependability advantages of a permanent and unchangeable read-only version of the memory image, and also to permit revisions to the setup.
In an operating system that is to be reconfigured, changes to the setup often require one or more reboots. Restarting may be needed to revert to a more basic system level and obtain a clean state from which changes can be made. If unsuccessful, in a disk operating system with a Restore function, restoring to an earlier operating system setup is possible and also requires a reboot, whereupon the complete previous setup is re-initiated. In an EWF XP-embedded system, one can choose not to write the memory buffer overlay, but this reverts completely to the previous setup with the next restart, instead of providing a way to access the old and new versions. What is needed is a better way to manage a protected memory block.
It would be an advantageous and substantial improvement on operating systems, including the EWF write-limited procedure discussed, if techniques could be provided whereby more options were made available to deal with the use of a flash memory or other non-volatile read/write memory device to make permanent some setup or other data value changes and not others.